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A method and apparatus for a communication system tech- 
nique involving ad hoc selection of at least two audio streams 
is provided. Each of the at least two audio streams is a pack- 
etized version of an audio source. A data connection exists 
between a server and a client where a transport protocol 
actively propagates the at least two audio streams from the 
server to the client. Furthermore, software instructions 
executable on the client indicate a presence of the at least two 
audio streams, allow selection of at least one of the at least 
two audio streams, and direct the selected at least one of the at 
least two audio streams for audio playback. 
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AD HOC SELECTION OF VOICE OVER 
INTERNET STREAMS 

CROSS-REFERENCE TO RELATED 

APPLICATIONS 5 

This application claims benefit of U.S. Provisional Appli- 
cation Ser. No. 60/350,906, filed Oct. 29, 2001, entitled 
“MCC voice over internet protocol (VOIP),” in the names of 
Mitchell Macha and John Bullock. 10 

STATEMENT REGARDING FEDERALLY 
SPONSORED RESEARCH AND DEVELOPMENT 

The invention described herein was made in the perfor- 15 
malice of work under a NASA contract and is subject to 
Public Law 96-517 (35 U.S.C. § 200 et seq.). The contractor 
has not elected to retain title to the invention. 

BACKGROUND OF INVENTION 20 

Transmission and reception of audio is a mainstay of 
human communication. For example, telephone, CB radio, 
FM/AM radio, and voice mail are typical implementations 
that provide auditory communication. While the telephone 25 
and the CB radio enable bi-directional communication, 
FM/AM radio and voice mail typically provide unidirectional 
communication. Unidirectional communication provides a 
means to convey instructions, information, alerts, and/or situ- 
ational awareness from an audio source to a listener. 30 

Situational awareness may provide an understanding of 
current or past events that may require present or future 
actions. For example, monitoring air traffic control, stock 
exchange broker conferences, mission control communica- 
tions, or police, fire, and EMS dispatch voice communica- 35 
tions provide an awareness. Typical situational awareness 
communications may convey routine activity or situations. 
However, by maintaining an awareness, unusual or critical 
situations may become apparent, and more information about 
the events that lead to the situation may be known by a listener 40 
much earlier. 

Systems that provide situational awareness are typically 
dedicated networks. In other words, dedicated networks are 
constructed for the sole purpose of conveying a particular 
type of information. For example, police, fire, and EMS dis- 45 
patch voice communications may have dedicated network(s) 
to route incoming information to an appropriate agency in a 
timely fashion. Air traffic control and stock exchange broker 
conferences may restrict the number of listeners due to con- 
cerns about security, privacy, subscription fees, and/or cost. 50 

Adding listeners to a communication system may be desir- 
able; however, the addition of listeners may involve extending 
the dedicated network(s). The ability to extend the dedicated 
network(s) may be limited due to a distance between an audio 
source and a listener, security/privacy concerns, and/or cost. 55 

SUMMARY OF INVENTION 

According to one aspect of the present invention, a com- 
munication system comprising a server arranged to actively 60 
propagate at least two audio streams where each of the at least 
two audio streams is a packetized version of an audio source; 
a client operatively connected to the server with a data con- 
nection where a transport protocol actively propagates the at 
least two audio streams from the server to the client; and 65 
software instructions executable on the client for indicating a 
presence of the at least two audio streams; selecting at least 


2 

one of the at least two audio streams dependent on a listener; 
and directing the selected at least one of the at least two audio 
streams for audio playback. 

According to one aspect of the present invention, a com- 
puter-readable medium having recorded thereon instructions 
executable by a processor, the instructions comprising 
instructions for indicating a presence of at least two audio 
streams actively propagated from a server; instructions for ad 
hoc selecting of at least one of the at least two audio streams 
dependent on a listener; and instructions for directing the 
selected at least one of the at least two audio streams for audio 
playback. 

According to one aspect of the present invention, a com- 
puter system for communications comprising a processor; a 
memory; and software instructions stored in the memory 
adapted to cause the computer system to indicate a presence 
of at least two audio streams actively propagated to a client; 
select at least one of the at least two audio streams dependent 
on a listener; and direct the selected at least one of the at least 
two audio streams for audio playback. 

According to one aspect of the present invention, a method 
for performing ad hoc selection of at least two audio streams 
comprising packetizing the at least two audio streams; 
actively propagating the at least two audio streams from a 
server to a client; indicating a presence of the at least two 
audio streams is performed by the client; selecting at least one 
of the at least two audio streams is performed by the client 
dependent on a listener; and directing the selected at least one 
of the at least two audio streams for audio playback. 

According to one aspect of the present invention, a com- 
munication system comprising means for packetizing at least 
two audio streams; means for actively propagating the at least 
two audio streams from a server to a client; means for indi- 
cating a presence of the at least two audio streams at the client; 
means for selecting at least one of the at least two audio 
streams at the client; and means for directing the selected at 
least one of the at least two audio streams for audio playback. 

Other aspects and advantages of the invention will be 
apparent from the following description and the appended 
claims. 

BRIEF DESCRIPTION OF DRAWINGS 

FIG. 1 illustrates a typical computer. 

FIG. 2 shows a block diagram of a communication system 
in accordance with an embodiment of the present invention. 

FIG. 3 shows a block diagram of a communication system 
in accordance with an embodiment of the present invention. 

FIG. 4 shows a flow diagram of software instructions 
executable on an encrypter in accordance with an embodi- 
ment of the present invention. 

FIG. 5 shows a flow diagram of software instructions 
executable on a client in accordance with an embodiment of 
the present invention. 

FIG. 6 shows an exemplary client controls window in 
accordance with an embodiment of the present invention. 

FIG. 7 shows a glossary for icons for an exemplary client 
controls window in accordance with an embodiment of the 
present invention. 

DETAILED DESCRIPTION 

In the following detailed description of the invention, 
numerous specific details are set forth in order to provide a 
more thorough understanding of the invention. However, it 
will be apparent to one of ordinary skill in the art that the 
invention may be practiced without these specific details. In 
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other instances, well-known features have not been described 
in detail to avoid obscuring the invention. 

Embodiments of the present invention relate to an active 
propagation of at least two audio streams from a server to a 
client and selecting at least one of the at least two audio 
streams using the client to be directed for audio playback. For 
the purposes of this disclosure, actively propagating the at 
least two audio streams from the server to the client refers to 
the client continuously receiving the at least two audio 
streams. In one or more embodiments, a listener may ad hoc 
select the at least one of the at least two audio streams to be 
directed for audio playback. For the purposes of this disclo- 
sure, ad hoc selection refers to the listener having the ability 
to select any, all, or none of the at least two audio streams 
continuously received at the client to be directed for audio 
playback. 

The invention may be implemented on virtually any type of 
computer regardless of the platform being used. For example, 
as shown in FIG. 1, a typical computer (24) includes a pro- 
cessor (26), memory (28), a storage device (30), and numer- 
ous other elements and functionalities typical of today’ s com- 
puters (not shown). The computer (24) may also include input 
means, such as a keyboard (32) and a mouse (34), and output 
means, such as a monitor (36). Those skilled in the art will 
appreciate that these input and output means may take other 
forms in an accessible environment. The computer (24) may 
be connected to a network (37) or other resources (not 
shown). 

FIG. 2 shows a block diagram of an exemplary communi- 
cation system (100 ) in accordance with an embodiment of the 
present invention. A plurality of audio sources are available at 
an audio source (102). An audio source may include audio 
signals and/or voice signals. For purposes of this disclosure, 
voice signals include those sounds manufactured by a living 
being, whereas audio signals include voice signals and all 
other signals that may be perceived by a listener. 

The audio source (102) provides a plurality of analog sig- 
nals on lines (114). One or more audioactive elements (104, 
106, 108, 110) convert the plurality of analog signals on lines 
(114) to a plurality of digital signals on lines (116). The 
audioactive elements (104, 106, 108, 110) also packetize the 
plurality of digital signals on lines (116). Packetization 
allows a digital signal to be separated into groups of bits, often 
referred to as packets. Accordingly, packets may be inter- 
spersed with other packets and propagated on a network or 
data connection using a transport protocol. A transport pro- 
tocol, for example, may include TCP/IP. Propagation on a 
network, e.g., an Ethernet based network, may use an address 
and a sequence number. The address determines a final des- 
tination for the packets and information about forwarding the 
packets from one computer or router to another computer or 
another router. The sequence number determines the proper 
order for the packets in case the packets are received out of 
order. Accordingly, a plurality of packets carrying digital 
signals from one of the audio sources is referred to as an audio 
stream. One of ordinary skill in the art will understand that 
multiple audio streams may be generated from a single audio 
source. Furthermore, multiple audio streams may be gener- 
ated from multiple audio sources. 

The audioactive elements (104, 106, 108, 110) may also 
encode the digital signals on lines (116). For example, the 
digital signals may be encoded in a MP3 (MPEG Audio Layer 
3) format, ITU G.723.1 voice coder format, or other format. 
Encoding may enable compression of the digital signals on 
lines (116). 

The packetized, and possibly, encoded digital signals on 
lines (116) use one or more hubs (120) to propagate the 
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packets to a voice over internet protocol (VOIP) encryption 
server (130). The propagation may use, for example, a uni- 
versal datagram protocol (UDP) service. The VOIP encryp- 
tion server (130) encrypts the packets such that unauthorized 
5 reception of encrypted packets does not allow the encrypted 
packets to be converted to a useful form. The encrypted pack- 
ets are propagated to a switch (140) using line(s) (133). One 
of ordinary skill in the art will understand that the encryption 
server (130) is representative of a device that encrypts the 
to packets (i.e., an encrypter). 

The encrypted packets may propagate from the VOIP 
encryption server (130), for example, as multicast packets 
(packets transmitted using the multicast transport protocol). 
The encrypted packets may be sent to a unique multicast 
1 5 addres s/ port combination. The unique multicast addres s/port 
combination provides the ability for audio players (182, 186, 
190, 196) operating on clients (180, 184, 188, 194) to receive 
and process each audio stream independently at a listener’s 
discretion, respectively. 

20 A campus intranet using multicast will see a total network 
load of the sum total of all of the audio streams regardless of 
the number of the listeners and the number of audio streams 
being monitored concurrently by the listeners. The VOIP 
encryption server (130) sends the encrypted packets as mul- 
25 ticast to the campus intranet. Routers (160, 164) in the cam- 
pus intranet distribute the encrypted packets as the multicast 
throughout the campus intranet with no further action being 
required of the VOIP encryption server (130). For example, 
encrypted packets may be uni-directionally propagated on 
30 lines (133, 143, 183, 163, 187, 191, 197). 

The audio players (182, 186, 190, 196) perform a variety of 
tasks that may include user authentication through a server 
such as an NT domain server (150), access verification using 
35 an access list (125), multicast join for each of the audio 
streams, decrypting the encrypted packets, directing the 
selected audio streams for audio playback, and modifying the 
audio playback. When an audio player (182, 186, 190, 196) 
starts, the listener is prompted for an ID and password. The 
40 audio player (182, 186, 190, 196) validates the listener 
against a specific NT domain server (150) database to assure 
authentication using lines (151, 161, 181, 185, 189, 195). 

Additionally, the audio player (182, 186, 190, 196) verifies 
that the listener has access authorization to the audio streams 
45 using an access list (125) and lines (127, 161, 181, 185, 189, 
195). User authentication may be afforded to a large number 
of listeners. Access list (125) authorization may be afforded 
to a reduced number of listeners, and may cause the audio 
player (182, 186, 190, 196) to indicate a presence of a limited 
50 number of the available audio streams. Once both of these 
checks are completed, a control window for the audio player 
(182, 186, 190, 196) is presented to the listener. One of 
ordinary skill in the art will understand that a plurality of lines 
connecting two or more elements may be physically routed on 
55 a plurality of lines or virtually routed on a single line. 

The audio player (182, 186, 190, 196) decrypts the 
encrypted packets received from the VOIP encryption server 
(130). The decrypting results in reproducing a copy of packets 
from an audio stream. The audio player (182, 186, 190, 196) 
60 directs the selected audio streams for audio playback. In one 
or more embodiments, the audio player (182, 186, 190, 196) 
may send the audio packets to a multimedia subsystem of the 
client (180, 184, 188, 194) using an application program 
interface. In one or more embodiments, the audio player (182, 
65 186, 190, 196) may send the audio packets to another device 
or software interface operatively connected to the client (180, 
184, 188, 194) for audio playback. 
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In one or more embodiments, the audio player (182, 186, 
190, 196) may allow modification of the audio playback of an 
audio stream. Modifying may include changing a volume, 
muting, and stopping an audio playback. In one or more 
embodiments, the audio player (182, 186, 190, 196) may also 
allow modification by stopping the propagation of an audio 
stream to the client (180, 184, 188, 194), starting the propa- 
gation of an audio stream to the client (180, 184, 188, 194), 
and flushing a stream buffer of an audio streams. 

One of ordinary skill in the art will understand that addi- 
tional lines between elements of the campus intranet may 
exist. The additional lines may enable communication not 
specifically described. For example, communication between 
the switch (140) and the router (160) may use line (141). 

In FIG. 2, the communication system (100) resides on a 
campus intranet. FIG. 3 shows a block diagram of an exem- 
plary communication system (200) in accordance with an 
embodiment of the present invention. The communication 
system (200) allows encrypted packets to travel beyond a 
campus intranet to a remote site intranet using, for example, 
an Internet (299). 

A plurality of audio sources are available at an audio source 
(202). An audio source may include audio signals and/or 
voice signals. The audio source (202) provides a plurality of 
analog signals on lines (214). One or more audioactive ele- 
ments (204, 206, 208, 210) convert the plurality of analog 
signals on lines (214) to a plurality of digital signals on lines 
(216). The audioactive elements (204, 206, 208, 210) also 
packetize the plurality of digital signals on lines (216). 

The audioactive elements (204, 206, 208, 210) may also 
encode the digital signals on lines (216). For example, the 
digital signals may be encoded in a MP3 (MPEG Audio Layer 
3) format, ITU G.723.1 voice coder format, or other format. 
Encoding may enable compression of the digital signals on 
lines (216). 

The packetized and possibly encoded digital signals on 
lines (216) use one or more hubs (220) to propagate the 
packets to a voice over internet protocol (VOIP) encryption 
server (230). The propagation may use, for example, a uni- 
versal datagram protocol service. The VOIP encryption 
server (230) encrypts the packets such that unauthorized 
reception of encrypted packets does not allow the encrypted 
packets to be converted to a useful form. The encrypted pack- 
ets are propagated to a switch (240) using line(s) (233). 

The encrypted packets may propagate from the VOIP 
encryption server (230), for example, as multicast packets. 
The encrypted packets may be sent to a unique multicast 
address/port combination. The unique multicast address/port 
combination provides the ability for audio players (282, 286, 
290) operating on clients (280, 284, 288) to receive and pro- 
cess each audio stream independently at a listener’s discre- 
tion, respectively. The VOIP encryption server (230) sends 
the encrypted packets as multicast to the campus intranet. 
Router (260) in the campus intranet distributes the encrypted 
packets as the multicast throughout the campus intranet with 
no fiirther action being required of the VOIP encryption 
server (230). For example, encrypted packets may be uni- 
directionally propagated on lines (233, 243, 273). 

A single campus intranet may be extended to a remote site 
intranet using, for example, an Internet (299). Encrypted 
packets may be propagated from the VOIP encryption server 
(230) to a VOIP UDP distribution server (296) using one or 
more switches and routers such as switch (240) and router 
(260). Encrypted packets may be uni-directionally propa- 
gated on lines (233, 243, 245). The VOIP UDP distribution 
server (296) allows the encrypted packets, even if using a 
multicast protocol, to be propagated through the Internet 


6 

(299) to the remote site intranet as UDP packets using lines 
(247, 287, 295). Additional routers, e.g., router (264), may 
propagate the UDP packets. A VOIP UDP distribution server 
(298) at the remote site intranet may recover the encrypted 
5 packets from the UDP packets and uni-directionally propa- 
gate the encrypted packets on lines (283, 285, 293). By using 
the multicast protocol, each of the campus intranet and the 
remote site intranet will see a total network load of the sum 
total of all of the audio streams, regardless of the number of 
to the listeners and the number of audio streams being moni- 
tored concurrently by the listeners. 

The audio player (282) performs a variety of tasks that may 
include user authentication through a server such as an NT 
domain server (250), access verification using an access list 
15 (225), multicast join for each of the audio streams, decrypting 
the encrypted packets, directing the selected audio streams 
for audio playback, and modifying the audio playback. When 
the audio player (282) starts, the listener is prompted for an ID 
and password. The audio player (282) validates the listener 
20 against a specific NT domain server (250) database to assure 
authentication using lines (251, 271). 

Additionally, the audio player (282) verifies that the lis- 
tener has access authorization to the audio streams using an 
access list (225) and lines (227, 271). User authentication 
25 may be afforded to a large number of listeners. Access list 
(225) authorization may be afforded to a reduced number of 
listeners, and may cause the audio player (282) to indicate a 
presence of a limited number of the available audio streams. 
Once both of these checks are completed, a control window 
30 for the audio player (282) is presented to the listener. 

Audio players (286, 290) perform a variety of tasks that 
may include user authentication through a server such as an 
NT domain server (292), access verification using an access 
list (228), multicast join for each of the audio streams, 
35 decrypting the encrypted packets, directing the selected audio 
streams for audio playback, and modifying the audio play- 
back. When the audio players (286, 290) start, the listener is 
prompted for an ID and password. The audio player (286, 
290) validates the listener against a specific NT domain server 
40 (292) database to assure authentication using lines (281 ,291, 
295). 

Additionally, the audio players verify that the listener has 
access authorization to the audio streams using an access list 
(228) and lines (229, 281, 291). User authentication may be 
45 afforded to a large number of listeners. Access list (228) 
authorization may be afforded to a reduced number of listen- 
ers, and may cause the audio players (286, 290) to indicate a 
presence of a limited number of the available audio streams. 
Once both of these checks are completed, a control window 
50 for the audio players (286, 290) is presented to the listener. 

One of ordinary skill in the art will understand that a 
plurality of lines connecting two or more elements may be 
physically routed on a plurality of lines or virtually routed on 
a single line. 

55 The audio player (282, 286, 290) decrypts the encrypted 
packets received from the VOIP encryption server (230). The 
decrypting results in reproducing a copy of packets from an 
audio stream. The audio player (282, 286, 290) directs the 
selected audio streams for audio playback. The audio player 
60 (282, 286, 290) may send the audio packets to a multimedia 
subsystem of the client (280, 284, 288) using an application 
program interface. The audio player (282, 286, 290) may send 
the audio packets to another device or software interface 
operatively connected to the client (280, 284, 288) for audio 
65 playback. 

One of ordinary skill in the art will understand that addi- 
tional lines between elements of the campus intranet may 
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exist. The additional lines may enable communication not 
specifically described. For example, communication between 
the switch (240) and the router (260) may use line (241). 

FIG. 4 shows an exemplary flow diagram (300) of software 
instructions executable on an encrypter in accordance with an 
embodiment of the present invention. The flow diagram (300) 
describes a process in which the encrypter encrypts an audio 
stream. In FIG. 2 for example, the VOIP encryption server 
(13 0) encrypts the packets from the audio streams propagated 
from the audioactive elements (104, 106, 108, 110). 

When an encrypter starts, a socket connection is estab- 
lished to one or more encoders that provides an audio stream 
(step 302). The socket connection may occur using a local 
area network (LAN). The encrypter also establishes a multi- 
cast connection to propagate data to one or more clients (step 
304). The multicast socket connection may occur using a 
wide area network (WAN). 

Once the socket connects are established (steps 302 and 
304), a packet from the encoders is read (step 306). The 
packet is assumed to be encoded in a MP3 format. The packet 
is encrypted (step 308). The encryption is assumed to be 
symmetrical RC4. One of ordinary skill in the art will under- 
stand that alternative encoding formats and encrypting algo- 
rithms may be used. The encrypted packet has a sequence 
number appended to protect against duplicate packet recep- 
tion (step 310). The encrypted packet with an appended 
sequence number is propagated on the WAN (step 312) and 
another packet from the encoders is read (step 306). Steps 306 
through 312 are then appropriately repeated. 

FIG. 5 shows an exemplary flow diagram (400) of software 
instructions executable on a client in accordance with an 
embodiment of the present invention. The flow diagram (400) 
shows a process in which a client establishes access to an 
encrypted audio stream and decrypts the encrypted packets 
for audio playback. When software instructions start for an 
audio player, for example audio players (182, 186, 190, 194) 
in FIG. 2, the software instructions request a listener to enter 
an ID and password (step 402). The ID and password are 
propagated to an authentication database (step 404). A com- 
parison of the ID and password entered in step 402 are com- 
pared to entries in the authentication database (step 406). If 
the comparison is successful, step 410 is followed. If the 
comparison is unsuccessful, step 408 is followed. In step 414, 
an error message is generated and steps 402, 404, and 406 are 
repeated. 

Once authentication has been achieved (step 406), access is 
determined (step 410). If a listener is on the access list, access 
to the audio streams is granted (step 412). Otherwise, access 
is not granted and the listener is sent back to step 402 via step 

414. 

In FIG. 5, an encrypted packet from the selected audio 
streams are decrypted and decoded (step 418). The decryp- 
tion is assumed to be symmetrical RC4. The packet is 
assumed to be encoded in a MP3 format. One or ordinary skill 
in the art will understand that alternative encoding formats 
and encrypting algorithms may be used that will result in 
alternative decoding and decrypting algorithms. The 
decrypted, decoded packet is directed for audio playback. 
Step 418 is repeated until the listener quits the software 
instructions (step 420). 

FIG. 6 shows an exemplary client controls window (500) in 
accordance with an embodiment of the present invention. 
Referring to FIG. 6, the client controls window (500) exists as 
a Graphical User Interface (GUI), for example, a floating 
window with buttons to select audio streams, buttons to 
modify the audio playback, and indicators to provide infor- 
mation about the selected audio streams and modifications to 
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the audio playback. A GUI is part of a software application 
that interacts with a listener via a graphical display. The GUI 
receives input from the listener through different modes of 
access, such as a mouse and pointer combination, or through 
5 a keyboard. A visual output of a GUI is typically displayed on 
a display device, such as a computer monitor screen, and 
includes widgets that allow the user to interact with the GUI. 
Examples of widgets include windows, captions, buttons, 
labels, menu bars, toolbars, dialog boxes, menus, icons, etc. 
l o Widgets may al so represent software applications that may be 
executed by the listener or a pointer icon that represents the 
position of the mouse. 

An exemplary GUI visual output of a client controls win- 
dow (500) is shown in FIG. 6. As shown, a client controls 
15 window (500) displays a text list indicating a presence of 
accessible audio streams in the left column. For example, 
International Space Station Flight Data 1 (ISS FD 1) (502) is 
one of nine accessible audio streams listed. Eight of the 
available nine audio streams are shown. Enlarging the client 
20 controls window allows the last audio stream to be displayed. 
Four of the nine audio streams are selected using the play 
buttons (504). The four selected audio streams are actively 
propagated on a data connection between a server and a client 
using a transport protocol. The remaining five audio streams 
25 are stopped, as indicated by the depressed stop buttons (506). 
The remaining five audio streams are not actively propagated 
to the client, however, all nine audio streams are actively 
propagated on a network by the server. Audio streams that are 
stopped may be started using play buttons (504). 

30 Audio streams that are playing may be stopped using stop 
buttons (506). Stopping a playback of an audio stream also 
stops that active propagation of the audio stream to the client. 

In FIG. 6, the four selected audio streams are directed for 
audio playback. The audio playback of the four selected audio 
35 streams may be modified. The audio playback of an audio 
stream may be muted using buttons (510). The volume of the 
four selected audio streams may be changed using slider 
buttons (512). The audio stream buffer may be flushed using 
buttons (508). 

40 In FIG. 6, indicators may provide information about the 
selected audio streams and modifications to the audio play- 
back of the selected audio streams. Check boxes (514) indi- 
cate that a selected audio stream has active packets being 
received by the client. A numerical indicator (516) indicates a 
45 number of packets currently in the audio stream buffer. A VU 
meter (518) provides an indicator of a playback audio volume 
magnitude. 

To begin listening to audio streams, a listener selects a play 
button (504) of one or more audio streams to monitor. The 
50 client controls window (500) spawns a read process for the 
selected audio streams and the spawned process performs a 
multicast join request for the selected audio streams. A router, 
for example router 164 in FIG. 2 and router 264 in FIG. 3) will 
process the multicast join request and will begin sending the 
55 encrypted multicast packets to the spawned process created 
by the client controls window (500). The spawned process 
created by the client controls window (500) will receive, 
decrypt, decode, and direct for playback the encrypted mul- 
ticast packets. As a volume or muting feature is changed by a 
60 listener, interrupts are send to the spawned process to change 
those attributes of the audio stream directed for playback. 

FIG. 7 shows a glossary (600) for icons for an exemplary 
client controls window in accordance with an embodiment of 
the present invention. A text (602) listing indicates a presence 
65 of accessible audio streams. A play button (604) starts an 
active propagation of an encrypted audio stream to a client, 
the client decrypts and decodes the audio stream, and directs 
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the audio stream for audio playback. The stop button (606) 
stops an active propagation of an encrypted audio stream to 
the client, and stops the audio playback of the audio stream. A 
button (608) flushes an audio stream buffer. A button (610) 
toggles between muting and unmuting an audio playback. A 
muted audio playback moves a volume of the audio playback 
to zero; however, the audio stream is still actively propagated, 
decrypted, decoded, and directed for audio playback. 

In FIG. 7, a slider button (612) adjusts the volume of an 
audio playback. A numerical indicator (614) indicates a num- 
ber of packets currently in an audio stream buffer. A VU meter 
(616) provides an indicator of a playback audio volume mag- 
nitude. An indicator (618) indicates that a client controls 
window has lost a connection to an audio stream(s). A button 
(620) causes a client controls window to display only the 15 
audio streams that are running. A button (622) causes a client 
controls window to display all of the audio streams that are 
accessible to a listener dependent on privilege. A button (624) 
flushes all audio stream buffers. A button (626) mutes an 
audio playback of all audio streams. A button (628) disables 20 
the mutes of an audio playback of all audio streams. A text 
indicator (630) displays the number of selected audio streams 
and the number of accessible audio streams. 

Advantages of the present invention may include one or 
more of the following. In one or more embodiments, because 25 
a packetized version of an audio source is propagated on a 
data connection between a server and a client, a dedicated 
connection does not have to be created between the audio 
source and a listener. 

In one or more embodiments, because a communication 30 
system includes audio streams, a data connection between a 
server and a client, an encrypter for encryption of the audio 
streams, and an audio player on the client that allows ad hoc 
selection of the audio streams, the communication system has 
a lower cost than a dedicated network and authentication and 35 
access maybe controlled. Furthermore, situational awareness 
may be extended to a larger number of listeners, often in the 
listener’ s usual business setting. A special listening area is not 
required. 

In one or more embodiments, a transport protocol includes 40 
a multicast protocol. A network load caused by propagating a 
plurality of audio streams will be a load of the plurality of the 
audio streams being propagated, regardless of the number of 
the listeners and the number of audio streams being moni- 
tored concurrently by the listeners. In other words, a network 45 
loading is dependent on the number of concurrent audio 
streams being actively propagated and not the number of 
listeners or the number of audio streams each listener has 
selected or hears. 

In one or more embodiments, a transport protocol includes 50 
a UDP protocol such that encrypted audio streams from a 
campus intranet may be extended to a remote site intranet. 

In one or more embodiments, because a plurality of audio 
streams is propagated to a client, multiple audio streams may 
be monitored simultaneously. Furthermore, ad hoc selection 55 
of actively propagated audio streams provides a listener the 
ability to monitor near real-time multiple concurrent audio 
streams. 

In one or more embodiments, an audio player allows a 
listener a capability to individually control audio volume and 60 
muting for each audio streams on a real-time basis. Additional 
modifications to each audio stream and indicators for each 
audio stream may advantageously be provided by the audio 
player to the listener. 

In one or more embodiments, a communication system is 65 
described that may provide monitor capability to supervisors 
of air traffic controller communication with Airline Pilots and 
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traffic controller training, stock exchange broker conference 
monitoring, and/or police, fire, or EMS dispatch monitoring. 
In addition, it would be possible to set up a web site for the 
general public to listen to select loops from their home com- 
5 puters. 

While the invention has been described with respect to a 
limited number of embodiments, those skilled in the art, 
having benefit of this disclosure, will appreciate that other 
embodiments can be devised which do not depart from the 
to scope of the invention as disclosed herein. Accordingly, the 
scope of the invention should be limited only by the attached 
claims. 

The invention claimed is: 

1 . A communication system, comprising: 
a server arranged to actively propagate at least two audio 

streams, wherein each of the at least two audio streams is 
a packetized version of an audio source, wherein each of 
the at least two audio streams are encoded; 
a client operatively connected to the server with a data 
connection, wherein a transport protocol actively propa- 
gates the at least two audio streams from the server to the 
client; and 

software instructions executable on the client for 

indicating a presence of the at least two audio streams; 
selecting at least one of the at least two audio streams 
dependent on a listener; 

directing the selected at least one of the at least two audio 
streams for audio playback; and 
decoding the selected at least one of the at least two 
audio streams directed for audio playback. 

2. A communication system, comprising: 
a server arranged to actively propagate at least two audio 

streams, wherein each of the at least two audio streams is 
a packetized version of an audio source, wherein the at 
least two audio streams are encrypted; 
software instructions executable on the server for encrypt- 
ing the at least two audio streams; 
a client operatively connected to the server with a data 
connection, wherein a transport protocol actively propa- 
gates the at least two audio streams from the server to the 
client; and 

software instructions executable on the client for 

indicating a presence of the at least two audio streams; 
selecting at least one of the at least two audio streams 
dependent on a listener; 

directing the selected at least one of the at least two audio 
streams for audio playback; and 
decrypting the selected at least one of the at least two 
audio streams directed for audio playback. 

3. A communication system, comprising: 
a server arranged to actively propagate at least two audio 

streams, wherein each of the at least two audio streams is 
a packetized version of an audio source; 
a client operatively connected to the server with a data 
connection, wherein a transport protocol actively propa- 
gates the at least two audio streams from the server to the 
client; and 

software instructions executable on the client for 

indicating a presence of the at least two audio streams; 
selecting at least one of the at least two audio streams 
dependent on a listener; 

directing the selected at least one of the at least two audio 
streams for audio playback; and 
modifying the audio playback, wherein modifying 
includes at least one selected from the group consist- 
ing of changing a volume of the selected at least one of 
the at least two audio streams, muting the selected at 
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least one of the at least two audio streams, flushing an 
audio stream buffer of at least one of the at least two 
audio streams, stopping the audio playback of the 
selected at least one of the at least two audio streams, 
stopping the actively propagating of the selected at 
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least one of the at least two audio streams, and starting 
the actively propagating of the selected at least one of 
the at least two audio streams. 



